Only hardlink if the source is a hardlink. - #2103
Conversation
|
At time of writing, this PR still has a small bug that if you twice include a file that's hardlinked ( Example: This PR restricts hardlinking to files known to be hardlinks, that is, if In this example above,
Solving this specific issue could be out of scope for #2102, so I think it's ok to leave unsolved. |
|
The test suite is repeatedly failing on Github Actions due to |
| require "fpm/version" | ||
| require "fpm/util" | ||
| require "clamp" | ||
| require "ostruct" |
There was a problem hiding this comment.
I added this to get rid of a Ruby warning about a future change: "warning: ostruct was loaded from the standard library, but will no longer be part of the default gems starting from Ruby 3.5.0."
Older rspec didn't allow a description to be given to satisfy(), but newer ones do. I think I forgot to include this rspec version update in PR #2103
Older rspec didn't allow a description to be given to satisfy(), but newer ones do. I think I forgot to include this rspec version update in PR #2103
In #2102, it was found that fpm would hardlink any file that's included in the package multiple times.
For example:
Notice above, /opt/example/one is a hardlink to /var/lib/example/one.
This behavior is not the intended behavior of fpm. The intended behavior (introduced in #365) was to ensure hardlinks in the original files are correctly kept as hardlinks in the package. The example in #365 was for git-core which has over 100 files hardlinked to the
gitexecutable such asgit-add,git-apply, etc. The problem in #365 was that fpm was copying these as individual files which resulted in hundreds of copies of the same file, and in git's case, thegitbinary is 18 megs.Now, in this PR, the intent is to retain the solution to #365 (#623) while removing the unintended behavior.
The above shows the buggy behavior.
With this PR, the package created looks like this:
Correctly two files, not hardlinked.